Skip to content

Internal: Refactor core classifications system to be based on harm identifiers instead#164

Open
turt2live wants to merge 14 commits into
mainfrom
travis/harms
Open

Internal: Refactor core classifications system to be based on harm identifiers instead#164
turt2live wants to merge 14 commits into
mainfrom
travis/harms

Conversation

@turt2live

@turt2live turt2live commented Jun 16, 2026

Copy link
Copy Markdown
Member

Reviewable commit-by-commit (strongly recommended).

The old confidence vectors system has finally been removed completely. A while ago we removed the ability for filters to return "spam: 0.8"-style classifications, so it effectively became a zero or one. As part of switching to harm IDs, we're removing the variability from the remaining structures.

The commit messages contain more information, especially around harm identifier use. In short: per MSC4456 we should be returning the most specific harm identifiers we can rather than all of them, so we do that. We also include a MSC4456-standard identifier whenever we return a custom one for backwards compatibility.

Fixes #167

TODO:

  • Fix filter tests
  • Fix any other bugs from manual/automated testing
  • Fix docs (eg: dropping spam threshold config, anything which mentions "vectors"). Check comments too.
  • Do a pass over the filters and media scanning to return "sensible" harm IDs (classifications were overlapping, harms aren't supposed to be)
  • Write more of a PR description to help review.

Pull Request Checklist

  • Pull request is based on the main branch.
  • Pull request title describes the changes in a way a user would understand. For example, "Fix keywords filter not applying" instead of "Read keywords slice in a loop".
  • Code style matches surrounding code.
  • Tests are added for new code (and existing code) if possible.
    • If not possible, please explain why in your PR description.
  • The CI checks pass.

turt2live added 13 commits June 24, 2026 18:10
The intention behind harm identifiers is to return the one(s) which are most applicable to the situation rather than all possible identifiers. This commit does this by returning the most specific identifiers it can rather than always appending SpamGeneral (for example). Where a policyserv-specific identifier is used, a non-custom identifier is also included for backwards compatibility. 

This commit also fixes a bug in the metrics where we were previously capturing index numbers rather than the actual classifications (oops).
A large portion of this code is to maintain backwards compatibility with older databases. Because policyserv might have a slow rollout in multi-process environments, we can't simply do a migration and expect it to work. We also don't want to migrate millions of rows if we don't have to.

This does mean we establish a ton of tech debt, however it's all in the name of backwards compatibility. We might never drop this tech debt to avoid an invasive database migration.
The intention behind harm identifiers is to return the one(s) which are most applicable to the situation rather than all possible identifiers. This commit does this by returning the most specific identifiers it can rather than always appending SpamGeneral (for example). Where a policyserv-specific identifier is used, a non-custom identifier is also included for backwards compatibility.
We were trying to persist a `nil` result, which doesn't work that well.

This should probably be fixed external to this PR, but given the code has been migrated to harm identifiers it seems best to wedge it in here.
@turt2live turt2live marked this pull request as ready for review June 25, 2026 19:18
@turt2live turt2live requested a review from a team as a code owner June 25, 2026 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use harm identifiers internally instead of classifications

1 participant